Hier mal ein Alternativvorschlag für ein Architekturdokument:
1 Einleitung
1.1 Zielsetzung (Purpose)
[Kurze Beschreibung der Zielsetzung des Dokumentes, z.B. „In diesem Dokument wird die Architektur der Warenwirtschaftsanwendung WWS anhand verschiedener Architektursichten (architecural Views) spezifiziert.]
1.2 Produktziele (Scope)
[Kurze Beschreibung der geplanten Software und ihrer Funktionalität.]
1.3 Definitionen, Akronyme und Abkürzungen
[Definition wichtiger Begriffe, Akronyme und Abkürzungen. An dieser Stelle kann auch ein Verweis auf ein separates Glossar stehen.]
1.4 Referenzen
[Liste aller Dokumente, auf verwiesen wird (z.B. Sollkonzept, ...). Zu jedem Dokument sind der Titel, Datum, Autor, Verlag (veröffentlichende Institution) anzugeben und Informationen dazu, wo/wie man das Dokument erhalten kann. An dieser Stelle kann auch ein Verweis auf die eigentliche Referenzliste im Anhang des Softwarearchitektur-Dokuments stehen.]
1.5 Überblick
[Kurze Beschreibung des weiteren Inhalts und des Aufbaus des Dokuments]
2 Darstellung der Architektur (Architectural Representation)
[kurze Auflistung und Erläuterung der verwendeten Sichten (Views)]
3 Rahmenbedingungen
[Dokumentation der Anforderungen und Ziele, die direkte Auswirkungen auf die Architektur besitzen (z.B. Sicherheitsanforderungen, Datenschutzrichtlinien, Portabilität, Verteilung der Anwendung, …). Daneben werden an dieser Stelle Vorgaben festgehalten, die sich auf Entwicklungswerkzeuge, Teamstrukturen, Zeitplan, legacy-Code, … beziehen.]
4 Geschäftsprozesse Use-Case View
[Falls die Geschäftsprozesse im Pflichtenheft noch nicht detailliert modelliert wurden, erfolgt diese Modellierung im folgenden Abschnitt. Zu jedem Use Case sind optional weitere Informationen anzugeben:
• Use Case Spezifikation
• Use Case Storyboard
• User Interface Prototyp
• Einordnung des Use Case in die Geschäftsprozesse (Business Use Case Specification)
• Fachkonzept-Klassen (Business Entities)
• Geschäftsregeln (Business Rules)
• Ergänzende Spezifikationen (Supplementary Specifications)
• Testfälle
Dabei ist je nach Use Case zu entscheiden, welche Informationen von den Entwicklern benötigt werden. Sind für einen Use Case bestimme Informationen irrelevant, so ist dies ebenfalls zu dokumentieren.]
4.1 Use Case Spezifikation
[Für die Spezifikation der Use Cases werden die einzelnen Geschäftsprozesse detaillierter untersucht und die darin aufgeführten Use Cases nach folgendem Schema dokumentiert:
1. Name des Use Cases
2. Kurzbeschreibung (Ziel)
3. Priorität (primär (notwendig, häufig benötigt), sekundär (notwendig, selten benötigt), optional (nützlich, nicht unbedingt notwendig)
4. Akteure
5. Beschreibung (Flow of Events)
6. Vorbedingungen
7. Nachbedingungen
8. Alternativen
9. Erweiterungen
10. Spezielle Anforderungen
]
4.2 Use Case Storyboard
[Ein Use Case Storyboard oder User Experience Storyboard gibt die Sicht des Anwenders auf den Use Case wieder, d.h. er beschreibt, über welche Folge von Bildschirmmasken ein Use Case durchgeführt wird und wie zwischen den verschiedenen Bildschirmmasken navigiert werden kann.
Beim Use Case Storyboard wird nicht das Layout der Masken betrachtet sondern rein die angezeigten Informationen und die Seitenfolge.]
4.3 User Interface Prototyp
[Im Gegensatz zum Use Case Storyboard wird beim User Interface Prototyp ein echter Prototyp der Benutzungsoberfläche erstellt, der mit den Anwendern diskutiert werden kann. Je nach Zielgruppe können hierbei Designaspekte (Schriftgröße, Schriftfarbe, Logo, ...) eine große Rolle spielen oder vernachlässigt werden, wenn es nur um die Struktur der Seiten und die darauf dargestellte Information geht.]
4.4 Einordnung des Use Case in die Geschäftsprozesse (Business Use Case Specification)
[Die Einordnung des Use Cases in die Geschäftsprozesse gibt Auskunft darüber, in welchem Geschäftsprozess der Use Case genutzt wird und an welcher Stelle des Geschäftsprozesses. Nur wenn ein Use Case in mindestens einem Geschäftsprozess genutzt wird, ist er zu realisieren.]
4.5 Fachkonzept-Klassen (Business Entities)
[Die Fachkonzeptklassen, die für die Realisierung des Use Cases benötigt werden, werden in Form von Klassendiagrammen dokumentiert. Ev. kann es sinnvoll sein, zusätzlich in Form von Interaktionsdiagrammen (Sequenz- oder Kollaborationsdiagrammen) zu beschreiben, wie der Use Case mit Hilfe der angegebenen Fachkonzept-Klassen realisiert wird.]
4.6 Geschäftsregeln (Business Rules)
[Geschäftsregeln sind z.B. immer dann anzugeben, wenn innerhalb des Use Cases Berechnungen durchgeführt werden. Die Geschäftsregeln geben dann die Berechnungsvorschrift an. Z.B. kann hier die Berechnung einer Spanne dokumentiert werden.]
4.7 Ergänzende Spezifikationen (Supplementary Specifications)
[In den ergänzenden Spezifikationen werden zusätzliche Informationen festgehalten, wie z.B. welche Zugriffsrechte ein Nutzer besitzen muss, um Use Cases ausführen zu dürfen, welche Aktivitäten nachvollziehbar sein müssen, welche Daten nicht gelöscht werden dürfen, ..... Dabei beziehen sich ergänzende Spezifikationen häufig auf mehrere Use Cases.]
4.8 Testfälle
[An dieser Stelle werden Testfälle für den Use Case festgehalten.]
5 Logische Sicht (Logical View)
[In der logischen Sicht der Anwendung wird die Gesamtanwendung in Subsysteme, Pakete und Komponenten zerlegt. Wichtige Pakete werden detaillierter in Form von Klassendiagrammen beschrieben]
5.1 Analysemodell
[Jedes Paket wird in einem eigenen Abschnitt beschrieben. Dabei ist für jedes Paket der Name, eine kurze Beschreibung und ein Diagramm mit allen wichtigen Klassen und Unterpaketen aufzuführen. Wichtige Klassen sind ebenfalls zu dokumentieren. Dabei sind neben dem Namen und einer kurzen Beschreibung wichtige Konsistenzbedingungen, Attribute, Operationen und die Verantwortlichkeiten der Klasse anzugeben.]
5.2 Entwurfsmodell
[Beim Übergang von der Analyse zum Entwurf wird das Analysemodell um technologische Aspekte und Verwaltungsklassen erweitert. Falls Transformationsregeln oder Entwurfsmuster für die Überführung des Analysemodells in das Entwurfsmodell genutzt werden sollen, sind sie an dieser Stelle zu dokumentieren.]
5.3 Datenmodell
[Dokumentation des Datenmodells. An dieser Stelle ist auch das O/R-Mapping zwischen Entwurfsmodell und Datenmodell zu spezifizieren.]
6 Prozess Sicht (Process View)
[In diesem Abschnitt wird das Zusammenspiel und die Kommunikation zwischen den Prozessen und Threads der Anwendung beschrieben.]
7 Verteilungssicht (Deployment View)
[Modellierung der Verteilung der Systemkomponenten auf Rechner bzw. Prozessoren und der Netzverbindungen (LAN, Bus, ...) zwischen den Rechnern.]
8 Implementierungssicht (Implementation View)
[Die Implementierungssicht beschreibt die durch die Implementierung entstehenden Quelldateien, ausführbaren Dateien, Archive (.jar, .ear, .war, ...). Der Fokus liegt dabei auf dem Management der Software-Teile. Die Implementierungssicht wirkt sich insbesondere auf das Konfigurations¬management aus.]
9 Migrationskonzept
[An dieser Stelle wird bei Bedarf die Migration von Altanwendungen beschrieben.]
10 Kapazität und Performanz
[Dimensionen, die Auswirkungen auf die Architektur und die Performanz haben (z.B. Anzahl gleichzeitiger Nutzer, ..).]
11 Qualität
[Kurze Beschreibung, wie die Architektur die im Pflichtenheft gestellten Qualitätsanforderungen (Erweiterbarkeit, Zuverlässigkeit, Portabilität, ...) unterstützt. ]
Version 0.1
Stand DD.MM.YYYY
Status In Bearbeitung
Autor Autor: Datei > Eigenschaften
Vorwort
Inhaltsverzeichnis
Abbildungsverzeichnis
Tabellenverzeichnis
1 Einleitung
Dieses Dokument beschreibt die Architektur für die Anwendung Appfahrt. Zum einen wird die Architektur des mobilen Clients der Anwendung beschrieben. Zum Anderen spezifiziert das Dokument den Aufbau des Bakendsystem. Auch das Zusammenspiel mit den Webservices der Drittanbietern wird erläutert.
2 Architekturtreiber 2.1 Architekturziele
2.1.1 Mobiler Teil der Anwendung
Die Anwendung muss auf aktuellen mobilen Endgeräten lauffähig sein. Mit dem Kunden wurde abgestimmt, dass der Teil der Anwendung, der auf dem mobilen Endgerät ausgeführt wird, für aktuelle Smartphones mit Android Betriebssystem lauffähig sein muss. Die Anwendung muss über einen Touchscreen bedienbar sein.
Das minimale Android-API, welches unterstützt werden muss ist das API-Level 7 (2.1 Eclair), denn 95.8% der Androidgeräte laufen mit diesem oder höreren Betriebssystem (Quelle: http://developer.android.com/resources/dashboard/platform-versions.html, Abruf 17.04.2011 17:30).
Auf dem Endgerät selbst sollen möglichst wenige Berechnungen und Aktivitäten ausgeführt werden um Energie zu sparen. Alle rechenintesiven Aktionen sollen möglichst im Backend bearbeitet werden.
Das Androidprogramm wird möglichst modular aufgebaut, damit eine hohe Wartbarkeit und Erweiterbarkeit realisiert werden kann.
2.1.2 Backend
Bei dem Backend soll möglichst auf freie Software zurückgegriffen werden, damit für die Produktivname keine oder wenig Lizenzkosten anfallen.
Des Weiteren soll das Backend modular und erweiterbar entwickelt werden. Das Backend muss standardschnittstellen bieten, damit es möglich ist, die Dienste mit weitere mobilen Endgeräten zu nutzen, die nicht mit dem Androidbetriebssystem ausgestattet sind.
2.2 Aufgabenstellung
2.3 Umzusetzende Systemanwendungsfälle
ID
Beschreibung
F01
Registrierung
F02
Anmeldung
F03
Pflege von Profildaten
F04
Mitfahrgelegenheit anbieten
F05
Mitfahrgelegenheit suchen
F06
Mitfahrgesuche anzeigen
F07
Benachrichtigungen bei passenden Reisezielen / Fahrtangeboten
F08
Bewertungen abgeben
F09
Passwort zurücksetzen
F10
Historie von Benutzern
F11
Administrative Eingriffe
O01
Ameldung an der Anwendung über Facebook
O02
Auf der Facebookseite des jeweiligen Users werden Fahrtangebote und –gesuche gepostet.
O03
Die aktuelle Position des Nutzers wird auf der zugehörigen Facebookseite aktualisiert
O04
Darstellung der Fahranbieter/Fahrtsucher auf einer Karte
O05
Anzeige von Fahrtsuchern die sich in der Nähe der Wegstrecke des Fahrers befinden.
3 Randbedingungen 3.1 Einzusetzende Konzepte und Komponenten
Zur Realisierung der Anwendung soll eine Schichenarchitektur entwickelt werden. Um eine schnelle Umsetzung zu ermöglichen werden gängige Frameworks verwendet. Die zu verwendenden Frameworks werden weiter unten in diesem Dokument spezifiziert.
Zu Darstellung von Karten wird die Komponente osmdroid in Kopplung von Cloudmade genutzt.
3.2 Einzuhaltende Konventionen
3.3 Sonstige Randbedingungen
4 Architekturskizze 4.1 Big-Picture
Die Abbildung AppFahrt-Schichten-Archtitektur zeigt einen Überblick über die einzelnen Schichten der Gesamtanwendung. Die Nutzung der Anwendung erfolgt über ein Gerät, welches unter dem Android-Betriebssystem läuft. Für diese Plattform wird eine Anwendung bereitgestellt. Eine alternative Zugriffsmöglichkeit ist ein aktueller Internetbrowser.
Für die Darstellung von Landkarten wird auf Drittanbieter zurückgegriffen (OSM/Cloudmade). Sämtlicher Datenaustausch zwischen dem mobilen Endgerät, dem Backend und dem Webservice des Drittanbieters erfolgt über das Internet. Als Kommunikationsprotocol wird http und https verwendet. Schützenwerte Daten werden ausschließlich über verschlüsselte Protokolle (https) übertragen.
Für statische Inhalte, als SSL-Endoint und zum Loadbalancing wird der Apache-Webserver verwendet. Der Tomcat-Applicationserver dient als Java-EE-Container für die Backendanwendung. In der Backendanwendung wird der Hauptteil der Anwendungslogik realisiert. Die Anwendungsdaten werden in einer Oracle 10.2 G persistiert.
4.2 Kontextsicht
4.3 Systemzerlegung 4.3.1 Backend-System
Der Application-Layer stellt die Grundlage für alle wesentlichen Prozesse und deren Geschäftslogik bereit. Der Layer stellt eine entsprechende Remote API für den Android-Layer bereitstellt. Neben der Anbindung der Android Applikation kapselt der Layer auch den Zugriff auf die Datenbank über entsprechende Services, die auf Data Access Objects zugreifen und zum Lesen bzw. zur Manipulation von Daten verwendet werden können.
Die Serviceschicht wird zustandslos implementiert.
Folgende Technologien werden im Rahmen der Entwicklung eingesetzt:
Spring
Das Springframework (Spring) ist ein Applikationsframework für die Java Plattform. Ziel von Spring ist es, die Entwicklung von Java/JavaEE Anwendungen zu vereinfachen. Dabei steht die Entkopplung einzelner Framework-Komponenten im Vordergrund. Dadurch können nur kleine Teile des inzwischen sehr großen Projekts verwendet werden. Durch die Verwendung von Dependency Injection auf Basis von AOP und Templates, wird ein POJO-basiertes Programmiermodell möglich, die Spring zu einem minimal-invasiven Framework machen.
Die in der Anwendung genutzten Services werden über Spring Beans realisiert. Hierdurch ist eine Anbindung über fast alle gängigen Schnittstellentechnologien implizit ohne größeren Aufwand möglich.
Webservices
Hibernate
Maven
Maven bietet unter anderem ein mächtiges Dependency Management und diverse Plugins, die den Buildzyklus vereinfachen.
Entwicklungsumgebung
Das Bauen des Produktes ist auch außerhalb der Entwicklungsumgebung über Maven möglich. IDE spezifische Projektdateien werden nicht mit in die Versionsverwaltung eingecheckt.
Jede moderne IDE bietet heute die Möglichkeit das Projekt über Maven Plugins zu importieren. Dies gewährleistet zugleich, dass keine personenbezogenen Pfade aus den Projektdateien fälschlicherweise verwendet werden.
4.4 Kategorisierung der Architektur
Es wird eine Schichtenarchitektur realisiert. 5 Architektursichten 5.1 Logische Sicht
5.1.1 Modell der Bausteintypen
5.1.1.1 Struktur der Bausteintypen
5.1.1.2 Eigenschaften der Bausteintypen 5.1.1.3 Schnitstellentypen
5.1.2 Anwendungsmodell
5.1.2.1 Struktur des Anwendungsmodells
5.1.2.2 Eigenschaften der Architekturbausteine
5.1.2.3 Schnittstellenbeschreibungen
5.1.2.4 Anwendungsdatentypen
5.2 Verteilungssicht (Technische Infrastruktur)
5.2.1 Technische Infrastruktur im Produktivbetrieb
5.2.1.1 Überblick
5.2.1.2 Eingesetzte Komponenten
5.2.2 Technische Infrastruktur der Entwicklungsumgebung
ACHTUNG! Änderungsstopp am 30.04.2011 17:00 Uhr!!
Architekturbeschreibung
TODO: Sebasitan 17.4
RUP Architekturdokument als Ergänzung: http://cin.ufpe.br/~if682/RUP/webtmpl/templates/bm/rup_barchdoc.htmHier mal ein Alternativvorschlag für ein Architekturdokument:
1 Einleitung
1.1 Zielsetzung (Purpose)
[Kurze Beschreibung der Zielsetzung des Dokumentes, z.B. „In diesem Dokument wird die Architektur der Warenwirtschaftsanwendung WWS anhand verschiedener Architektursichten (architecural Views) spezifiziert.]
1.2 Produktziele (Scope)
[Kurze Beschreibung der geplanten Software und ihrer Funktionalität.]
1.3 Definitionen, Akronyme und Abkürzungen
[Definition wichtiger Begriffe, Akronyme und Abkürzungen. An dieser Stelle kann auch ein Verweis auf ein separates Glossar stehen.]
1.4 Referenzen
[Liste aller Dokumente, auf verwiesen wird (z.B. Sollkonzept, ...). Zu jedem Dokument sind der Titel, Datum, Autor, Verlag (veröffentlichende Institution) anzugeben und Informationen dazu, wo/wie man das Dokument erhalten kann. An dieser Stelle kann auch ein Verweis auf die eigentliche Referenzliste im Anhang des Softwarearchitektur-Dokuments stehen.]
1.5 Überblick
[Kurze Beschreibung des weiteren Inhalts und des Aufbaus des Dokuments]
2 Darstellung der Architektur (Architectural Representation)
[kurze Auflistung und Erläuterung der verwendeten Sichten (Views)]
3 Rahmenbedingungen
[Dokumentation der Anforderungen und Ziele, die direkte Auswirkungen auf die Architektur besitzen (z.B. Sicherheitsanforderungen, Datenschutzrichtlinien, Portabilität, Verteilung der Anwendung, …). Daneben werden an dieser Stelle Vorgaben festgehalten, die sich auf Entwicklungswerkzeuge, Teamstrukturen, Zeitplan, legacy-Code, … beziehen.]
4 Geschäftsprozesse Use-Case View
[Falls die Geschäftsprozesse im Pflichtenheft noch nicht detailliert modelliert wurden, erfolgt diese Modellierung im folgenden Abschnitt. Zu jedem Use Case sind optional weitere Informationen anzugeben:
• Use Case Spezifikation
• Use Case Storyboard
• User Interface Prototyp
• Einordnung des Use Case in die Geschäftsprozesse (Business Use Case Specification)
• Fachkonzept-Klassen (Business Entities)
• Geschäftsregeln (Business Rules)
• Ergänzende Spezifikationen (Supplementary Specifications)
• Testfälle
Dabei ist je nach Use Case zu entscheiden, welche Informationen von den Entwicklern benötigt werden. Sind für einen Use Case bestimme Informationen irrelevant, so ist dies ebenfalls zu dokumentieren.]
4.1 Use Case Spezifikation
[Für die Spezifikation der Use Cases werden die einzelnen Geschäftsprozesse detaillierter untersucht und die darin aufgeführten Use Cases nach folgendem Schema dokumentiert:
1. Name des Use Cases
2. Kurzbeschreibung (Ziel)
3. Priorität (primär (notwendig, häufig benötigt), sekundär (notwendig, selten benötigt), optional (nützlich, nicht unbedingt notwendig)
4. Akteure
5. Beschreibung (Flow of Events)
6. Vorbedingungen
7. Nachbedingungen
8. Alternativen
9. Erweiterungen
10. Spezielle Anforderungen
]
4.2 Use Case Storyboard
[Ein Use Case Storyboard oder User Experience Storyboard gibt die Sicht des Anwenders auf den Use Case wieder, d.h. er beschreibt, über welche Folge von Bildschirmmasken ein Use Case durchgeführt wird und wie zwischen den verschiedenen Bildschirmmasken navigiert werden kann.
Beim Use Case Storyboard wird nicht das Layout der Masken betrachtet sondern rein die angezeigten Informationen und die Seitenfolge.]
4.3 User Interface Prototyp
[Im Gegensatz zum Use Case Storyboard wird beim User Interface Prototyp ein echter Prototyp der Benutzungsoberfläche erstellt, der mit den Anwendern diskutiert werden kann. Je nach Zielgruppe können hierbei Designaspekte (Schriftgröße, Schriftfarbe, Logo, ...) eine große Rolle spielen oder vernachlässigt werden, wenn es nur um die Struktur der Seiten und die darauf dargestellte Information geht.]
4.4 Einordnung des Use Case in die Geschäftsprozesse (Business Use Case Specification)
[Die Einordnung des Use Cases in die Geschäftsprozesse gibt Auskunft darüber, in welchem Geschäftsprozess der Use Case genutzt wird und an welcher Stelle des Geschäftsprozesses. Nur wenn ein Use Case in mindestens einem Geschäftsprozess genutzt wird, ist er zu realisieren.]
4.5 Fachkonzept-Klassen (Business Entities)
[Die Fachkonzeptklassen, die für die Realisierung des Use Cases benötigt werden, werden in Form von Klassendiagrammen dokumentiert. Ev. kann es sinnvoll sein, zusätzlich in Form von Interaktionsdiagrammen (Sequenz- oder Kollaborationsdiagrammen) zu beschreiben, wie der Use Case mit Hilfe der angegebenen Fachkonzept-Klassen realisiert wird.]
4.6 Geschäftsregeln (Business Rules)
[Geschäftsregeln sind z.B. immer dann anzugeben, wenn innerhalb des Use Cases Berechnungen durchgeführt werden. Die Geschäftsregeln geben dann die Berechnungsvorschrift an. Z.B. kann hier die Berechnung einer Spanne dokumentiert werden.]
4.7 Ergänzende Spezifikationen (Supplementary Specifications)
[In den ergänzenden Spezifikationen werden zusätzliche Informationen festgehalten, wie z.B. welche Zugriffsrechte ein Nutzer besitzen muss, um Use Cases ausführen zu dürfen, welche Aktivitäten nachvollziehbar sein müssen, welche Daten nicht gelöscht werden dürfen, ..... Dabei beziehen sich ergänzende Spezifikationen häufig auf mehrere Use Cases.]
4.8 Testfälle
[An dieser Stelle werden Testfälle für den Use Case festgehalten.]
5 Logische Sicht (Logical View)
[In der logischen Sicht der Anwendung wird die Gesamtanwendung in Subsysteme, Pakete und Komponenten zerlegt. Wichtige Pakete werden detaillierter in Form von Klassendiagrammen beschrieben]
5.1 Analysemodell
[Jedes Paket wird in einem eigenen Abschnitt beschrieben. Dabei ist für jedes Paket der Name, eine kurze Beschreibung und ein Diagramm mit allen wichtigen Klassen und Unterpaketen aufzuführen. Wichtige Klassen sind ebenfalls zu dokumentieren. Dabei sind neben dem Namen und einer kurzen Beschreibung wichtige Konsistenzbedingungen, Attribute, Operationen und die Verantwortlichkeiten der Klasse anzugeben.]
5.2 Entwurfsmodell
[Beim Übergang von der Analyse zum Entwurf wird das Analysemodell um technologische Aspekte und Verwaltungsklassen erweitert. Falls Transformationsregeln oder Entwurfsmuster für die Überführung des Analysemodells in das Entwurfsmodell genutzt werden sollen, sind sie an dieser Stelle zu dokumentieren.]
5.3 Datenmodell
[Dokumentation des Datenmodells. An dieser Stelle ist auch das O/R-Mapping zwischen Entwurfsmodell und Datenmodell zu spezifizieren.]
6 Prozess Sicht (Process View)
[In diesem Abschnitt wird das Zusammenspiel und die Kommunikation zwischen den Prozessen und Threads der Anwendung beschrieben.]
7 Verteilungssicht (Deployment View)
[Modellierung der Verteilung der Systemkomponenten auf Rechner bzw. Prozessoren und der Netzverbindungen (LAN, Bus, ...) zwischen den Rechnern.]
8 Implementierungssicht (Implementation View)
[Die Implementierungssicht beschreibt die durch die Implementierung entstehenden Quelldateien, ausführbaren Dateien, Archive (.jar, .ear, .war, ...). Der Fokus liegt dabei auf dem Management der Software-Teile. Die Implementierungssicht wirkt sich insbesondere auf das Konfigurations¬management aus.]
9 Migrationskonzept
[An dieser Stelle wird bei Bedarf die Migration von Altanwendungen beschrieben.]
10 Kapazität und Performanz
[Dimensionen, die Auswirkungen auf die Architektur und die Performanz haben (z.B. Anzahl gleichzeitiger Nutzer, ..).]
11 Qualität
[Kurze Beschreibung, wie die Architektur die im Pflichtenheft gestellten Qualitätsanforderungen (Erweiterbarkeit, Zuverlässigkeit, Portabilität, ...) unterstützt. ]
Version 0.1
Stand DD.MM.YYYY
Status In Bearbeitung
Autor Autor: Datei > Eigenschaften
Vorwort
Inhaltsverzeichnis
Abbildungsverzeichnis
Tabellenverzeichnis
1 Einleitung
Dieses Dokument beschreibt die Architektur für die Anwendung Appfahrt. Zum einen wird die Architektur des mobilen Clients der Anwendung beschrieben. Zum Anderen spezifiziert das Dokument den Aufbau des Bakendsystem. Auch das Zusammenspiel mit den Webservices der Drittanbietern wird erläutert.
2 Architekturtreiber
2.1 Architekturziele
2.1.1 Mobiler Teil der Anwendung
Die Anwendung muss auf aktuellen mobilen Endgeräten lauffähig sein. Mit dem Kunden wurde abgestimmt, dass der Teil der Anwendung, der auf dem mobilen Endgerät ausgeführt wird, für aktuelle Smartphones mit Android Betriebssystem lauffähig sein muss. Die Anwendung muss über einen Touchscreen bedienbar sein.
Das minimale Android-API, welches unterstützt werden muss ist das API-Level 7 (2.1 Eclair), denn 95.8% der Androidgeräte laufen mit diesem oder höreren Betriebssystem (Quelle: http://developer.android.com/resources/dashboard/platform-versions.html, Abruf 17.04.2011 17:30).
Auf dem Endgerät selbst sollen möglichst wenige Berechnungen und Aktivitäten ausgeführt werden um Energie zu sparen. Alle rechenintesiven Aktionen sollen möglichst im Backend bearbeitet werden.
Das Androidprogramm wird möglichst modular aufgebaut, damit eine hohe Wartbarkeit und Erweiterbarkeit realisiert werden kann.
2.1.2 Backend
Bei dem Backend soll möglichst auf freie Software zurückgegriffen werden, damit für die Produktivname keine oder wenig Lizenzkosten anfallen.
Des Weiteren soll das Backend modular und erweiterbar entwickelt werden. Das Backend muss standardschnittstellen bieten, damit es möglich ist, die Dienste mit weitere mobilen Endgeräten zu nutzen, die nicht mit dem Androidbetriebssystem ausgestattet sind.
2.2 Aufgabenstellung
2.3 Umzusetzende Systemanwendungsfälle
ID
Beschreibung
3 Randbedingungen
3.1 Einzusetzende Konzepte und Komponenten
Zur Realisierung der Anwendung soll eine Schichenarchitektur entwickelt werden. Um eine schnelle Umsetzung zu ermöglichen werden gängige Frameworks verwendet. Die zu verwendenden Frameworks werden weiter unten in diesem Dokument spezifiziert.
Zu Darstellung von Karten wird die Komponente osmdroid in Kopplung von Cloudmade genutzt.
3.2 Einzuhaltende Konventionen
3.3 Sonstige Randbedingungen
4 Architekturskizze
4.1 Big-Picture
Die Abbildung AppFahrt-Schichten-Archtitektur zeigt einen Überblick über die einzelnen Schichten der Gesamtanwendung. Die Nutzung der Anwendung erfolgt über ein Gerät, welches unter dem Android-Betriebssystem läuft. Für diese Plattform wird eine Anwendung bereitgestellt. Eine alternative Zugriffsmöglichkeit ist ein aktueller Internetbrowser.
Für die Darstellung von Landkarten wird auf Drittanbieter zurückgegriffen (OSM/Cloudmade). Sämtlicher Datenaustausch zwischen dem mobilen Endgerät, dem Backend und dem Webservice des Drittanbieters erfolgt über das Internet. Als Kommunikationsprotocol wird http und https verwendet. Schützenwerte Daten werden ausschließlich über verschlüsselte Protokolle (https) übertragen.
Für statische Inhalte, als SSL-Endoint und zum Loadbalancing wird der Apache-Webserver verwendet. Der Tomcat-Applicationserver dient als Java-EE-Container für die Backendanwendung. In der Backendanwendung wird der Hauptteil der Anwendungslogik realisiert. Die Anwendungsdaten werden in einer Oracle 10.2 G persistiert.
4.2 Kontextsicht
4.3 Systemzerlegung
4.3.1 Backend-System
Der Application-Layer stellt die Grundlage für alle wesentlichen Prozesse und deren Geschäftslogik bereit. Der Layer stellt eine entsprechende Remote API für den Android-Layer bereitstellt. Neben der Anbindung der Android Applikation kapselt der Layer auch den Zugriff auf die Datenbank über entsprechende Services, die auf Data Access Objects zugreifen und zum Lesen bzw. zur Manipulation von Daten verwendet werden können.
Die Serviceschicht wird zustandslos implementiert.
Folgende Technologien werden im Rahmen der Entwicklung eingesetzt:
Spring
Das Springframework (Spring) ist ein Applikationsframework für die Java Plattform. Ziel von Spring ist es, die Entwicklung von Java/JavaEE Anwendungen zu vereinfachen. Dabei steht die Entkopplung einzelner Framework-Komponenten im Vordergrund. Dadurch können nur kleine Teile des inzwischen sehr großen Projekts verwendet werden. Durch die Verwendung von Dependency Injection auf Basis von AOP und Templates, wird ein POJO-basiertes Programmiermodell möglich, die Spring zu einem minimal-invasiven Framework machen.
Die in der Anwendung genutzten Services werden über Spring Beans realisiert. Hierdurch ist eine Anbindung über fast alle gängigen Schnittstellentechnologien implizit ohne größeren Aufwand möglich.
Webservices
Hibernate
Maven
Maven bietet unter anderem ein mächtiges Dependency Management und diverse Plugins, die den Buildzyklus vereinfachen.
Entwicklungsumgebung
Das Bauen des Produktes ist auch außerhalb der Entwicklungsumgebung über Maven möglich. IDE spezifische Projektdateien werden nicht mit in die Versionsverwaltung eingecheckt.
Jede moderne IDE bietet heute die Möglichkeit das Projekt über Maven Plugins zu importieren. Dies gewährleistet zugleich, dass keine personenbezogenen Pfade aus den Projektdateien fälschlicherweise verwendet werden.
4.4 Kategorisierung der Architektur
Es wird eine Schichtenarchitektur realisiert.
5 Architektursichten
5.1 Logische Sicht
5.1.1 Modell der Bausteintypen
5.1.1.1 Struktur der Bausteintypen
5.1.1.2 Eigenschaften der Bausteintypen
5.1.1.3 Schnitstellentypen
5.1.2 Anwendungsmodell
5.1.2.1 Struktur des Anwendungsmodells
5.1.2.2 Eigenschaften der Architekturbausteine
5.1.2.3 Schnittstellenbeschreibungen
5.1.2.4 Anwendungsdatentypen
5.2 Verteilungssicht (Technische Infrastruktur)
5.2.1 Technische Infrastruktur im Produktivbetrieb
5.2.1.1 Überblick
5.2.1.2 Eingesetzte Komponenten
5.2.2 Technische Infrastruktur der Entwicklungsumgebung
5.2.2.1 Überblick
5.2.2.2 Eingesetzte Komponenten
5.3 Laufzeitsicht
5.4 Implementierungssicht
5.5 Schnittstellenübersicht
6 Querschnittliche Systemeigenschaften
6.1 Ablaufsteuerung (Workflow, Systemsteuerung)
6.2 Persistenz
6.3 Validierung
6.4 Oberfläche (GUI)
6.5 Druckausgaben
6.6 Transaktionsmanagement
6.7 Skalierbarkeit
6.8 Caching
6.9 Sessionmanagement
6.10 Security
6.11 Benutzerverwaltung
6.12 Mandantenfähigkeit
6.13 Audit, Versionierung
6.14 Integration/Kommunikation mit anderen IT-Systemen
6.15 Monitoring
6.16 Backup, Archivierung
6.17 Sicherheit im Betrieb
6.18 Tracing und Logging
6.19 Fehlermanagement
6.20 Konfigurierbarkeit
6.21 Internationalisierung
6.22 Migration
6.23 Performance
6.24 Gewährleistung der Testbarkeit
7 Architekturabsicherung
7.1 Dokumentation von Entscheidungen
7.1.1 Grundsätzliche Entscheidungskriterien
7.1.2 Architekturentscheidungen
7.1.3 Technologie-Entscheidungen
7.1.4 Make-Buy-or-Reuse-Entscheidungen
7.2 Anwendungsfall-Realisierungen
8 Aspekte Betrieb, Rollout und AM
8.1 Einführung, Rollout
8.2 Betrieb
8.3 Applikationsmanagement (AM)
9 Teilsystem <n>
9.1 Überblick
9.2 Logische Sicht
9.3 Datensicht
9.4 Implementierungssicht
Abkürzungsverzeichnis
Quellenverzeichnis